Agile Testing Condensed Japanese Edition
https://cdn-ak.f.st-hatena.com/images/fotolife/n/nihonbuson/20200411/20200411005518.png
(読了 : 2020-05-29)
セクション 1 : 基礎
アジャイルテストの核心は、プロダクトの品質の構築やテストにチーム全体が関与すること 欠陥を見つけるためのセーフティネットとしてテスターを頼るのではなく、チームが欠陥を防ぐことを学ぶという思考の変化
アジャイルテストが意味するものとは？
テストマニフェスト
最後にテストするよりもずっとテストし続ける
バグの発見よりもバグの防止
機能性をチェックするよりもテストの理解
システムを破壊するよりも最高のシステムを構築する
テスターの責任よりも品質に対するチームの責任
チーム全体のアプローチとアジャイルテストのマインドセット
DoD には、コードで見つかった欠陥にチームがどのように対処するかを含める必要がある
チームが欠陥に対処する方法
コーディング完了後に欠陥を見つけるのではなく、欠陥を防ぐことに焦点を当てる
チームの複数の人の視点・観点を利用することで、デリバリー時のリスクをよりよく理解できる
アジャイルにおけるテスト計画
セクション 2 : テストアプローチ
例を用いて開発を導く
実例に基づく実践 :
具体的な例を使うことの利点 : 新機能から顧客が得る価値を、チームがより正確に把握できる
協調を可能に
顧客と協調
通常はプロダクトオーナーが担当する
顧客が解決しようとしている問題をチームが理解していない場合、チームは間違った問題を解決する可能性があるので、理解が重要。 チーム全員がドメインを理解することを推奨
以下のような質問ができる
「これをどのように使用しますか？」
「最悪の事態は何ですか？」
使えるフレームワーク
継続的な探索
ペルソナを役割や業務に組み合わせるとより良い
チームは顧客にとっての価値を見落としがち。 それらに焦点を当てるよう探索的テストを設計できる
「起こりうる最悪の事態は何ですか？」 「起こりうる最高のことは何か」
経験を最大限に活用するためにペア作業を推奨
アプリケーションについて学ぶのに必要な情報を整理するのに役立つ
既成概念にとらわれない追加の技法 :
品質特性 (非機能的な要件) のテスト
品質特性の 2 つの種類
開発の特性 : コードの保守性、コードの再利用性、テスト容易性
運用の特性
品質テストについてはデリバリーチームが積極的に考えること (プロダクトオーナーは品質特性を当然のものと考えることが多い)
DevOps のテスト
デプロイとリリースの違い
デプロイしても機能を隠しておくことはできる
実働環境のテスト
リリースフィーチャーの切り替えの手法や、A/B テストなど
https://gyazo.com/1e61593e2e8fb4fd57043c6386a543a3
セクション 3 : 役立つモデル
テストの四象限
https://gyazo.com/043626804785d5906bb0715b47d59457
ストーリー完了に含めることができるテストは、第 1 象限 (左下) と第 2 象限 (左上) の全てと、第 3 象限 (右上) の一部
さらにフィーチャー完了も定義できる
ストーリーレベルでテストできなかった品質特性のテストはフィーチャーレベルで実行するのがおすすめとのこと
テストの自動化戦略の視覚化
セクション 4 : 今日のアジャイルテスト
テスターの新たな役割
テスターの役割は複数のアクティビティで構成される
ステークホルダーとの協力、全体的な品質戦略の整理と調整、リスクの特定など……
最近だと、品質特性に 「チームの健全性」 を追加し始めた (それも品質に大きな影響を与えるもの)
成功の材料
チームを導くための成功要因
チーム全体のアプローチ : テストはフェーズではなく活動
アジャイルテストの考え方 : テスターはもはや品質警察ではなく、「止める / 進む」 を判断する
回帰テストを自動化する : チーム全体を考えて、全てのレベルで自動化
フィードバックの提供と取得 : 迅速なフィードバックが大事。 意図しない変更があったらすぐに気づく、など。 テスターはフィードバックループの作成と短縮の中心にいる
コアプラクティスの基盤構築 : 継続的な統合とか、テスト環境とか、技術的な負債の管理とか、変更を分割するとか
顧客との協調
全体像を見る
信頼関係構築のプラクティス
実例を使う
探索的テストをする
フィーチャーをテストする
継続的に学習する
状況に敏感になる
常に現実的に
成功への道